\chapter{Tests i resultats}
\section{Metodologia}
En aquest capítol s'exposaran els resultats dels tests realitzats per comparar l'aplicació creada amb el programari existent.
En tots els programes s'han utilitzat certificats de 1024 bits i s'ha activat la compressió permesa per cada l'aplicació; el motiu d'activar la compressió és que la llibreria OpenSSL utilitzada per la creació del \keyword{VPMN}{Virtual Private Mesh Network} (el programa creat en aquest projecte) no permet desactivar la compressió en temps d'execució.
L'escenari dels tests consta d'una xarxa Gigabit Ethernet on hi estan connectats dos ordenadors:
\begin{enumerate}
\item Debian GNU/Linux (PC amd64)
\begin{itemize}
\item AMD Athlon 64 X2 Dual Core Processor BE-2400 (2.3GHz, 1024KB cache)
\item nForce Gigabit Ethernet CK804
\end{itemize}
\item Debian GNU/Linux (PC i686)
\begin{itemize}
\item Intel Pentium M Centrino Processor (1.70GHz, 2048KB cache)
\item Realtek Gigabit Ethernet RTL-8169
\end{itemize}
\end{enumerate}
%TODO:
%Afegir retards als tests
%Tests de Compressio
\subsection{Eficiència}
Per analitzar l'eficiència dels programes s'analitzen els bytes transmesos durant la inicialització, en el cas de la connexió directe es conten els bytes de les peticions \keyword{ARP}{Address Resolution Protocol} i en la resta de casos s'exclouen.
També s'analitzen els bytes transmesos durant l'enviament de paquets \keyword{ICMP}{Internet Control Message Protocol} de \emph{echo} (\emph{ping}) de 56 bytes (contant la capa IP són 84 bytes/paquet).
Els resultats es contaran en bytes sense comptar la capa Ethernet (14 bytes/trama).

En el moment d'analitzar els resultats s'ha de tenir en compte que TincVPN no intercanvia certificats durant la inicialització: en el seu lloc les claus públiques dels altres nodes s'han d'instal·lar al configurar el programari (per tenir una idea del que ocupen 2 certificats de 1024 bits: $830\cdot2=1660$ bytes).
També s'ha de tenir en compte que els diferents programes utilitzen diferents algoritmes de compressió. 

\subsection{Latència}
Per analitzar la latència dels diferentes programes es realitzen les mesures amb el programa \emph{ping}. S'han realitzat 100 mesures en intervals de 2 segons per donar temps als algoritmes del programari VPN.

\subsection{Taxa màxima de transferència}
Per analitzar la taxa màxima de transferència s'han realitzat els tests amb 2 programes diferents: netperf i MGEN.
El netperf s'ha utilitzat per realitzar tests en TCP i UDP, aquests tests es realitzen enviant grans blocs d'informació a través dels protocols esmentats.
El MGEN s'ha utilitzat amb la configuració de la taula \ref{T:mgencfg} per tal d'enviar paquets a 737.28 Mbps durant 10 segons, i mesurant el nombre de paquets rebuts s'ha calculat la taxa rebuda.
\begin{table}[htb]
\begin{center}
\begin{minipage}[htb]{0.6\linewidth}
\footnotesize
\begin{verbatim}
TXBUFFER 1000
0.0 ON  1 UDP DST 10.0.0.1/5000 PERIODIC [90000.0 996]
10.0 OFF 1
\end{verbatim}
\end{minipage}
\caption{Configuració MGEN}
\label{T:mgencfg}
\end{center}
\end{table}

En la taula \ref{T:mgencfg}, la configuració del MGEN utilitzada, encomana enviar 90000 paquets UDP per segon amb un \emph{payload} UDP de 996 bytes, resultant així paquets IP de 1024 bytes. Per a calcular la taxa de recepció s'utilitza l'equació \ref{E:mgen}, tenint en compte que l'activitat del MGEN es realitza només durant 10 segons.

\begin{minipage}[htb]{\linewidth}
\begin{equation}\label{E:mgen}
r=P\cdot\frac{(996+28)\cdot8}{10}
\end{equation}
\centering
{\scriptsize
r: Taxa de recepció (bps). 
P: Número de paquets rebuts. 
}\\
%Equació \ref{E:mgen}: Càlcul de la tassa de recepció del MGEN.
\vspace{1em}
\end{minipage}

En interpretar els resultats obtinguts s'ha de tenir en compte la presència de la compressió durant els tests del programari VPN. Aquesta pot afectar a la comparativa de la taxa de recepció si el tràfic generat té diferents ratis de compressió depenent dels algoritmes utilitzats en cada programari.

La llibreria OpenSSL només pot treballar amb un sol \emph{thread} per connexió, per tant la utilització de \emph{threads} en l'aplicació creada en aquest projecte (VPMN) només es veuria beneficiada en un context de vàries connexions.

%Proves amb varis nodes
%\subsection{Capacitat}
%\subsection{Càrrega}
%\subsection{Escalabilitat}

\section{Anàlisi de resultats}
Abans d'analitzar els resultats cal comentar els problemes trobats durant les proves amb el programa creat. 
Ja durant els primers tests d'aquesta aplicació es van notar comportaments anòmals amb la recepció de tràfic xifrat i s'ha invertit molt de temps en intentar trobar l'arrel d'aquest problema. Per mirar de sol·lucionar-lo es va intentar canviar la part que treballa amb el xifratge amb diferents algoritmes i estructures. Finalment, després de depurar molt el programa, s'ha pogut trobar que el comportament anòmal ve donat per la llibreria OpenSSL, que sembla que falla al cap d'un temps aleatori \cite{dtls-error} malgrat aparentment l'aplicació fa un bon ús d'ella. Per tant sembla que la recent implementació de DTLS d'aquesta llibreria conté errors que afecten a l'ús que se'n fa en aquesta aplicació. S'ha observat que aquests errors es produeixen més sovint quan transiten paquets de mides diferents; i canviar l'algoritme de xifratge també canvia la forma de percebre l'error.
El poc ús que rep aquest protocol, i per tant la seva implementació en la OpenSSL, fa que no s'hagi pogut trobar documentat aquest possible error, però s'ha començat a buscar l'error dins del codi font de la llibreria \cite{dtls-error}. Per altre banda s'ha trobat una altre aplicació (propietària), que fa ús del mateix protocol, però utilitza la llibreria OpenSSL modificada \cite{dtls-cisco} sense alliberar els canvis que hi han realitzat.

Com a conseqüència dels problemes esmentats, els tests d'aquesta aplicació s'han hagut de realitzat nombroses vegades abans de poder obtenir un resultat.

Per analitzar els resultats cal tenir en compte que tal com s'ha descrit l'escenari, algunes aplicacions tenen un comportament diferent:
\begin{itemize}
\item Les aplicacions utilitzen algoritmes de compressió i xifratge diferents.
\item El OpenVPN no realitza tasques d'enrutament intern en el node client al haver-hi una instància servidor i una client: tant el TincVPN com el VPMN realitzen aquestes tasques en ambdós nodes.
\item El TincVPN no intercanvia certificats ni claus públiques; el seu protocol, tal com està descrit en el capítol \ref{TincVPN-Sec}, no compleix tots els requisits per a ser un protocol segur.
\end{itemize}

En la taula \ref{T:efi} es compara l'\textbf{eficiència} en el tràfic.
\begin{table}[htb]
\begin{center}
\begin{tabular}{|c|r|r|}
\multicolumn{1}{c}{} & \multicolumn{2}{|c|}{Mida (bytes)} \\ \hline
Aplicació & Inicialització & Ping \\ \hline \hline
\tt directe & 112 & 84 \\ \hline
OpenVPN & 11876 & 153 \\ \hline
TincVPN & 2569 & 136 \\ \hline
\bf VPMN & 4641 & 169 \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Eficiència}
\label{T:efi}
\end{center}
\end{table}
Es pot veure com el OpenVPN intercanvia notablement més informació durant la inicialització, més del doble del tràfic generat pel VPMN.
El TincVPN es manté per sota de les altres aplicacions, però aquest no intercanvia certificats durant la inicialització. Afegint un intercanvi de 2 certificats serien 4229 bytes i estaria a prop del VPMN però encara mantenint-se per sota; afegint els 2 certificats més, el de la CA de cada un, aquest hauria d'enviar 5889 bytes i es quedaria entre el OpenVPN i el VPMN. Per tant es pot dir que TincVPN envia poca informació d'inicialització gràcies a l'absència d'aquest intercanvi.
La negociació ARP de la connexió directe està molt per sota de les inicialitzacions de les altres aplicacions, per tant com ja es podia predir el contingut que necessiten transportar els paquets ARP és molt menor al de qualsevol negociació de les aplicacions VPN.

També és el TincVPN el que aconsegueix la millor eficiència en la transferència dels paquets \emph{ping}. Les altres aplicacions resulten estar molt a prop d'aquest resultat però aquesta vegada OpenVPN millora l'eficiència al VPMN. En aquest test la mida original, mesurada en la connexió directe, no s'allunya molt dels resultats dels paquets xifrats.

En la taula \ref{T:lat} es compara la \textbf{latència} mesurant el \keyword{RTT}{Round-Trip Time}.
\begin{table}[htb]
\begin{center}
\begin{tabular}{|c|c|c|c|c|c|}
\multicolumn{2}{c}{} & \multicolumn{4}{|c|}{RTT (ms)} \\ \hline
Aplicació & Pèrdues & Mínim & Mitjana & Màxim & D.Estàndard \\ \hline \hline
\tt directe & 0\% & 0.047 & 0.050 & 0.074 & 0.006 \\ \hline
OpenVPN & 0\% & 0.199 & 0.479 & 5.333 & 1.080 \\ \hline
TincVPN & 0\% & 0.136 & 0.185 & 0.911 & 0.092 \\ \hline
\bf VPMN & 0\% & 0.228 & 0.310 & 0.415 & 0.034 \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Latència}
\label{T:lat}
\end{center}
\end{table}
La mínima latència és la del TincVPN i la màxima és la del OpenVPN. VPMN es manté entremig però amb una desviació estàndard molt inferior a la dels altres dos programaris. La desviació estàndard major és la de OpenVPN, i aquest també enregistra valors màxims molt elevats per estar en una xarxa local. Els resultats de la latència en connexió directe només donen una referència de que l'escenari utilitza una xarxa local.

En la taula \ref{T:tax} es compara la \textbf{taxa màxima de transferència}.
\begin{table}[htb]
\begin{center}
\begin{tabular}{|c|c|c|r|}
\multicolumn{1}{c}{} & \multicolumn{3}{|c|}{Màxim (Mbps)} \\ \hline
Aplicació & TCP & UDP & MGEN \\ \hline \hline
\tt directe & 690.49 & 929.91 & 116.03 \\ \hline
OpenVPN & 185.01 & 500.37 & 78.52 \\ \hline
TincVPN & 133.26 & 270.77 & 78.29 \\ \hline
\bf VPMN & 188.09 & 193.28 & 96.17 \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Taxa màxima de transferència}
\label{T:tax}
\end{center}
\end{table}
L'aplicació que arriba a la màxima taxa és la OpenVPN amb tràfic UDP: és el valor més proper a la connexió directe (només superant lleugerament la meitat d'aquest valor).
L'aplicació TincVPN té valors molt baixos en TCP.
El programa creat en aquest projecte (VPMN), malgrat tenir un bon resultat en TCP i MGEN, es manté en velocitats semblants tant en TCP com en UDP.

Per tant es pot observar com en treballar amb paquets grans els resultats són molt diferents dels d'eficiència. En aquest test però també s'hi veu representada l'eficiència dels algoritmes interns, de xifratge i d'enrutament (OpenVPN només enruta en un node).

El test del MGEN al utilitzar UDP hauria de donar resultats semblants als del test de UDP però en canvi dóna resultats ben diferents. Primerament no arriba a enviar els aproximadament 740 Mbps, sinó uns 116 Mbps. Per tant el programari està treballant en condicions més normals de les de taxa màxima. Concloent, el resultat del test amb MGEN dóna uns resultats estranys possiblement per la manera de mesurar la velocitat.

A continuació es fa un \textbf{resum} de la secció.
El OpenVPN realitza una inicialització extensa, te una latència gran juntament amb una desviació estàndard alta i permet taxes de transferència grans.
El TincVPN realitza una inicialització molt breu, te una latència molt baixa i permet taxes de transferència baixes.
L'aplicació creada realitza una inicialització breu, te una latència baixa juntament amb una desviació estàndard molt baixa i permet taxes de transferència altes en TCP i baixes en UDP (en comparació amb les de les altres aplicacions).
